Para ser honesto, siempre me ha confundido docker exec -it … , docker exec -i … y docker exec -t … , así que decido hacer una prueba:
docker exec -it … :
# docker exec -it 115c89122e72 bash root@115c89122e72:/# ls bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr varFunciona normalmente.
docker exec -i … :
# docker exec -i 115c89122e72 bash ^CEl comando se cuelga y tengo que usar Ctl + c para interrumpirlo.
docker exec -t … :
# docker exec -t 115c89122e72 bash root@115c89122e72:/# ls ^CEntra en el contenedor con éxito, pero se bloquea al ejecutar el primer comando.
Así que parece que no tiene sentido tener los comandos docker exec -i … y docker exec -t … ¿Alguien podría explicar por qué existen las opciones -i y -t para el comando docker exec ?
-i , --interactive mantiene STDIN abierto incluso si no está adjunto, lo que necesita si desea escribir cualquier comando.
-t , --tty un pseudo-TTY, un pseudo terminal que conecta el "terminal" de un usuario con stdin y stdout. (Ver container/container.go )
Si hace un eco, solo se necesita -t .
Pero para una sesión interactiva en la que ingresa entradas, necesita -i .
Dado que -i mantiene abierta la entrada estándar, también se usa para canalizar la entrada a un contenedor acoplable separado. Eso funcionaría incluso con -d (separar).
Consulte " ¿Cuándo usaría --interactive sin --tty en un contenedor Docker? ":
$ echo hello | docker run -i busybox cat hello
-iSTDIN abierto incluso si no está conectado, ¿cuál es el estado de STDOUT en este caso?
Es, para docker exec , el establecido por docker run .
Pero, con respecto a docker exec , hay un problema actual ( problema 8755: Docker tty no es un tty con docker exec
desafortunadamente, su descubrimiento solo equivale a una diferencia entre el comportamiento de tty en centos6 frente a ubuntu: 14.04. Todavía no hay un tty funcional dentro del exec: solo haga
ls -la /proc/self/fd/0y vea que es un enlace roto que apunta a unptsque no existe.el error real con el que estamos lidiando es que ciertas bibliotecas estándar asumen que los enlaces simbólicos en /proc/self/fds/ deben ser enlaces simbólicos válidos
El problema es que el tty se crea fuera del host y no hay ninguna referencia a él en el contenedor, como la configuración de
/dev/consoleen el contenedor principal.
Una opción para solucionar esto sería asignar y montar losdevptsdel host en los contenedores.
Nota (cuarto trimestre de 2017): esto ya debería estar solucionado (docker 17.06-ce) .
Ver PR 33007 .
Ese PR ahora permite (desde el 17.06):
zacharys-pro:dev razic$ docker run --rm -t -d ubuntu bash 83c292c8e2d13d1b1a8b34680f3fb95c2b2b3fef71d4ce2b6e12c954ae50965a zacharys-pro:dev razic$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 83c292c8e2d1 ubuntu "bash" 2 seconds ago Up 1 second xenodochial_bardeen zacharys-pro:dev razic$ docker exec -ti xenodochial_bardeen tty /dev/pts/1 (antes del 17.06, tty devolvía " not a tty ")